It has become clear to telecommunications carriers that voice traffic and services will be one of the next major applications to take advantage of the Internet Protocol (IP). This expectation is based on the impact of a set of technologies generally referred to as voice over IP (VoIP) or IP telephony. VoIP supplies many unique capabilities to carriers and customers using IP or other packet-based networks. The most important benefits include cost savings and integrated voice and data networks.
By moving voice traffic to IP networks, companies may reduce or eliminate certain toll charges associated with transporting calls over the Public Switched Telephone Network (PSTN). Service providers and end users can also conserve bandwidth by investing in additional capacity as needed. This is made possible by the distributed nature of VoIP and by reduced operations costs as companies combine voice and data traffic onto one network. By making voice “just another IP application,” companies can build truly integrated networks for voice and data. These integrated networks not only provide the quality and reliability of today's PSTN, they also enable companies to quickly and flexibly take advantage of new opportunities within the changing world of communications.
Around 1995, the first commercial VoIP products began to hit the market. These products were targeted at companies looking to reduce telecommunications expenses by moving voice traffic to packet networks. Early adopters of VoIP networks built toll-bypass solutions to take advantage of the fact that local exchange carriers (LECs) were not able to bill access charges on voice call placed through the Internet. Without any established standards, most early implementations were based on proprietary technology. As these packet telephony networks grew and interconnection dependencies emerged, it became clear that the industry needed standard VoIP protocols. Several groups took up the challenge, resulting in several independent standards, each with its own unique characteristics. Currently, four different signaling and call control protocols for VoIP are popular: H.323; Media Gateway Control Protocol (MGCP); H.248/Megaco; and Session Initiation Protocol (SIP).
H.323 is an ITU Recommendation that defines “packet-based multimedia communications systems.” In other words, H.323 defines a distributed architecture for creating multimedia applications, including VoIP. Media Gateway Control Protocol (MGCP), also known as IETF RFC 2705, defines a centralized architecture for creating multimedia applications, including VoIP. H.248, also referred to as IETF RFC 2885 (Megaco), is an ITU Recommendation that defines a “Gateway Control Protocol.” H.248 is the result of a joint collaboration between the ITU and the Internet Engineering Task Force (IETF) which defined a centralized architecture for creating multimedia applications, including VoIP. In many ways, H.248 builds on and extends MGCP. Session Initiation Protocol (SIP), also known as IETF RFC 3261, defines another distributed architecture for creating multimedia applications, including VoIP. It is also worth mentioning the Real-Time Transport Protocol (RTP), also known as IETF RFC 1889, which defines a transport protocol for real-time applications used by all of the VoIP signaling protocols. Specifically, RTP provides the transport to carry the audio/media portion of VoIP communication.
Interexchange carriers (IXCs) are starting to build networks to facilitate the use of VoIP across their service areas. These networks are being added to the exiting PSTN to form a combined network. Such combined networks (i.e. networks relying on different bearer technologies and/or signaling protocols such as PSTN and packet networks such as TCP/IP or ATM) are typically termed interconnected dissimilar networks or hybrid networks. Present estimates are that at least some IXCs offload up to 25% of their traffic onto packet networks. It is envisioned that packet networks will eventually replace switched networks due to cost and reliability factors. However, as with many technologies in the telephony area, acceptance has been slower than some would like.
The various dissimilar networks in a hybrid network are typically interconnected via gateways that provide the necessary conversions or adaptations between the bearer traffic and possibly signaling protocol in each of the networks. The operating characteristics of gateways are defined by the various signaling and call control protocols, i.e. H.323; Media Gateway Control Protocol (MGCP); H.248/Megaco; and Session Initiation Protocol (SIP).
FIG. 1 is a simplified schematic view illustrating a MGCP communication environment 100 having a packet network 106 and a public switched telephone network (PSTN) 112. The MGCP protocol provides a comprehensive solution for the control of gateways, termed Media Gateways (MG(s)) in the specification of the protocol. MGCP is based on the principle that all call processing intelligence resides in the MGC. The MG does not retain knowledge of call state; it provides only the capability to cross-connect various kinds of media streams under the control of the MGC and to detect and transmit various kinds of signaling associated with those media streams.
MGCP views MGs as a collection of terminations, each of which represents a certain kind of media stream. A termination may be a fixed physical entity such as an analog line or a digital signal level 0 (DS-0) time slot in a DS-1 interface, or it may be a logical entity such as a voice-over-IP (VoIP) packet stream. Logical terminations may be created and destroyed by means of MGCP commands.
Cross-connections within an MG are created by means of MGCP commands that request two or more terminations to be placed in the same context. If the media streams associated with terminations that are in the same context are of different types (for instance, one is a DS-0 time slot while the other is a VoIP packet stream), the MG is expected to perform appropriate media conversion between them. To support this, terminations have various media stream properties associated with them such as the identity of the voice encoding that is to be used.
Terminations have other properties, such as a list of signaling events that they are expected to notify to the MGC and a list of signals that they are capable of transmitting on request from the MGC. For example, an analog line termination should be capable of notifying the MGC when it sees an off-hook or an on-hook event; it should also be capable of applying ringing on the line when requested by the MGC. The events and signals that are associated with a specific type of termination are described in a package.
Referring once again to FIG. 1, the PSTN 112 generally includes a bearer portion 126, over which user traffic, such as a telephone call using time division multiplexed (TDM) is communicated, and a signaling portion 128 over which signaling traffic, such as SS7 traffic, is carried. The packet network 106 can be, for example, an asynchronous transfer mode (ATM) network, an internet protocol (IP), or any other packet switching network.
The communication environment 100 also includes a media gateway controller (MGC) 102, which, when coupled with a signaling gateway 162, is sometimes referred to as a “softswitch” 164. The MGC 102 communicates with a media gateway (MG) 105 via the packet network 106 and communication lines 132 and 143. The signaling gateway 162 communicates with the PSTN 112 via connection 136. A Trunking media gateway 104 couples the packet network to the PSTN 112 via connection 144. Trunking media gateways are special gateways that interconnect a packet network to the PSTN, while generic MGs generally serve VoIP customers. The MGC 102 may also be coupled, via the PSTN 112, to one or more other media gateway controllers, an exemplar one of which is illustrated using reference numeral 108. Further, although not shown in FIG. 1, two MGCs may communicate over the packet network 106 using, for example, the SIP protocol.
A first switch (switch A) 114 connects to the PSTN 112 via connection 152 and a second switch (switch B) 116 connects to the PSTN 112 via connection 154. The switches 114 and 116, are typically considered part of the PSTN 112, and are may be located at telephone company central offices (not shown). By way of example, a telephone 124 is shown coupled to switch 114 via connection 156 and a telephone 122 is shown coupled to switch 116 via connection 158. A phone 118 is shown connected to the media gateway 105 via connection 146.
As known to those having ordinary skill in the art, both user traffic and signaling information typically traverse both the packet network, 106 and the PSTN 112. The links 136 and 148 typically carry PSTN signaling traffic, such as signaling system seven (SS7) integrated services digital network user part (ISUP) or telephone user part (TUP) signaling messages. The connections 132, 142, and 143 typically carry packet network signaling traffic in the form of packets constructed using, in this example, the media gateway control protocol (MGCP).
User traffic, for example a telephone call that might occur between telephones 118 and 124, typically traverses communication links 146, 143, 142, 144, 152 and 156. Because the call traverses both the packet network 106 (communication lines 143 and 142) and the PSTN 112 (communication lines 144, 152 and 156), the user traffic (telephone call) is identified by two different communication protocols. In this example, the packet portion of the call signaling is identified using the MGCP protocol, while the PSTN portion of the call, signaling is identified using the SS7 ISUP protocol. The use of different protocols mean that not only are the set up and tear down messages different but even the naming conventions for devices on the connection are completely different.
A call setup message in the SS7 ISUP protocol would take the form of an initial address message (IAM), while a call tear-down message in the SS7 ISUP protocol would take the form of a release message (REL) or a release complete message (RLC). Conversely, in the packet network 106 using MGCP, a call setup message would take the form of a create connection (CRCX) message while a call tear-down message would take the form of a delete connection (DLCX) message. Further, while described using call setup and call tear-down messages, other signaling messages (that typically occur between the setup and tear-down messages) in both the SS7 and MGCP protocols will traverse the dissimilar communication networks.
In the packet network 106, communication endpoints, such as the MG 105 are characterized by their “endpoint name,” which typically takes the form “user identifier@domain.xxx,” while in the PSTN 112, a call is identified by a point code (PC) that relates to its originating point code (OPC), destination point code (DPC) and the circuit, identified by its circuit identification code (CIC), on which it is carried.
Because the signaling used in a single phone call between telephone 118 and 124 is characterized by two separate communication protocols (SS7 ISUP on the PSTN side and MGCP on the packet side), it is difficult to provide a single end to end call record, commonly referred to as a call detail record (CDR) because of the two different communication protocols used to signal the call. Of course, if all carriers implemented packet switching networks using a single protocol and cross connects said networks, the task of providing a single end to end call record would be simplified.
At the present time, most LECs currently do not have the facilities to even accept packet traffic, meaning the IXC must pass the traffic through a trunking media gateway—converting the traffic back to a circuit switched call. For many of the reasons cited hereinabove, not the least of which is the cost savings to be realized if IP-IP connection can be made between LECs and IXC, many LECs desire to move toward sending and receiving packet traffic rather than traditional switched traffic. However, most LECs are cautious and do not want to implement packet network gateways until they can be guaranteed that IXCs will fill such packet networks with revenue generating traffic or that these connections will be reliable.
In general, the allocation of revenue between carriers is handled using “tariffs.” The term tariff generally refers to documents filed by a regulated telephone company with a state public utility commission detailing services, equipment and pricing offered by a telephone company to all potential customers. Historically, to settle the tariffs for access charges between IXCs and LECs (the charge from the destination LEC to the IXC for completing the circuit on the local network), the IXCs would self-report the minutes of use for traffic that satisfied each tariff, for example local or long distance connections, intrastate connections, interstate connections, transit connections, etc. Using SS7 based operation support systems (OSS), LEC are able to verify many of the so-called factors (the percentage of traffic that falls under each tariff) on circuit switched interconnections.
At the present time tariffs for VoIP traffic have not been finalized. Existing access charge methodologies now in place assume all traffic between LECs and IXCs is circuit switch based. However, the FCC has yet to issue a ruling as to whether VoIP traffic is an enhanced service exempt from regulation and access charges. To add further confusion, several states have recently issued conflicting decisions regarding the oversight and taxing of VoIP traffic. Accordingly, both IXCs and LEC need a billing system that is flexible enough to handle the current tariffs along with future tariffs that may be radically different.
Unfortunately for LECs, at the present time only IXCs have the capability to determine the percentage of VoIP traffic on their networks. As traffic is passed across a gateways, LECs have no access to information that confirms the percentage of packet traffic they receive. IXCs could provide SS7 parameters regarding such traffic, but no standard exits for such data. LECs are desirable of receiving accurate and verifiable records of VoIP traffic to ensure compliance with existing and future tariffs. LECs are also desirable of receiving accurate and verifiable factors regarding the VoIP traffic to ensure compliance with tariffs.
The inventors have recognized that a different approach is needed to monitor VoIP traffic, simplify the management and reconciliation of carrier to carrier access charges, and still allow the identifications, jurisdictionalization and correlation of VoIP telephony traffic transiting carrier boundaries.